fix(studio): a stale project id in the URL no longer blocks editing for the tab - #4188

APPROVE — the bug is real, the fix targets the right equivalence, and the tri-state is the correct shape. One gap worth closing and one smaller observation, both non-blocking, written out so you can decide rather than take my word for the grading.

Verified at source

• The 404 contract the tri-state rests on holds. GET /projects/:id (packages/studio-server/src/routes/projects.ts:51-53) has exactly one 404 in it: adapter.resolveProject(...) returning null. No mustExist, no other status in the handler. So "404 ⟺ the server cannot resolve this id" is true for this route, which is what makes acting on missing safe.
• "Matching the /api/projects list would be wrong twice over" — both halves check out, and this is the most interesting decision in the PR:
  • Session ids. listProjects keys entries on the project directory name (packages/studio/vite.adapter.ts:197, id: d.name) and carries the session only as a separate sessionId field, so a session id is never in the list's id set. resolveProject explicitly falls through to sessions/<id>.json and resolves it (:211-227). Matching against the list would have redirected a working session deep link.
  • Dirs without an index. listProjects filters on index.html || <name>.html (:191-192); resolveProject has no such filter and returns the dir if it exists (:235). Resolvable, unlisted.
• Encode/decode symmetry. parseProjectIdFromHash decodes (projectRouting.ts:64) and resolveHashProject re-encodes with encodeURIComponent, so an id containing a space or a % is not double-encoded on the way to the probe.
• The mutation claims are true by inspection, and the tests are not vacuous. Removing the fallback kills "falls back when the hash id is gone"; collapsing unknown into missing kills both keep-the-hash tests. The fallback test's list project (real-project) is deliberately different from the hash id, so it proves the hash id lost rather than merely that something was set.

The gap: nothing re-validates after mount

resolveHashProject runs inside useMountEffect. The hook's own hashchange listener is untouched and still adopts any later id with no check:

// useServerConnection.ts:107-114 — unchanged by this PR
const next = parseProjectIdFromHash(window.location.hash);
if (next && next !== projectId) setProjectId(next);

The reachable sequence is one click, and this PR is what creates it:

1. Load #project/deleted-project → the probe 404s → fall back and window.location.hash = buildProjectHash("demo-capture") (:86). Assigning to location.hash pushes a history entry.
2. The user presses Back — plausible, because from their side the app just silently moved them off the project they asked for.
3. The hash returns to #project/deleted-project, hashchange fires, setProjectId("deleted-project") runs unvalidated. The mount effect has already run, so nothing rewrites it again: the tab is back in the exact 404-for-its-lifetime state, with the same absent telemetry.

So the title's "for the tab" holds for the load path, and stops holding one Back press later. Two ways out, not equivalent:

• history.replaceState(null, "", buildProjectHash(first.id)) instead of assigning location.hash. The dead id never enters history, so Back leaves the page rather than restoring it. Cheapest, and it does not depend on the hashchange firing since projectId is already set at :84.
• Route onHashChange through resolveHashProject. Covers the general case too — pasting a stale hash into a live tab — at the cost of an async listener.

I would take the first unless in-tab hash edits are a real path for you, in which case the second is the actual fix.

Why I am not blocking on it: that listener behaved identically before this PR, so nothing regresses, and the load path you targeted is genuinely fixed. What would flip it is treating the silent redirect as the user-visible recovery — Back is the normal response to being redirected.

Smaller: the hash path can now reach the retry loop

missing plus an empty project list falls through to scheduleRetry() (:88), which sets waitingForServer and polls every 2 s. A hash-carrying load could not reach that before, because the hash short-circuited above it. On a healthy server that simply has no projects, the user now sits in the waiting-for-server state indefinitely, which names the wrong cause. Narrow, and still better than the old silent breakage — worth a line only because it is a new state for this path rather than a change in degree.

Scope

I read both changed files whole, plus the three untouched pieces the fix depends on: the route's 404 origin, both adapter project resolvers, and the hash codec. I did not run the suite — the 843-pass number is from your body, and the mutation claims above I checked by reading, not by executing.

— Rames